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Abstract 

N<'t\v<jrk Xionitoring is very usetul in diagnosing network related problems. Most 
of 1ii(' (‘.xisting iK'twork monitors give a snapshot of the network during the time of 
ilu'ir t'X(‘cution. \Vc have developed tools which monitor the network and store the 
irafiic suimnari<\s over a period of time. This stored information aids in analysis 
of the 1 rathe generated. Two tools, a Protocol Analyzer and an NFS Analyzer 
hav<‘ been dt'V(’iope<l. 'The Protocol Analyzer captures the network traffic through 
a promiscuously ct)ntigured Hthornet interface, and stores the protocol summaries. 
Tlie .NFS .-Xiialy/.er monitors NFvS traffic and stores filesystem load levels and other 
related information. 
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Chapter 1 
Introduction 


.W'twork Managt'int'al is very important in day-to-day running of computer systems 
in a nei\vork«'<} environment. Network management needs information about the 
iK'twork like l>aTui\vi<ith utilization, protocol summaries, load on fileservers, and 
other r<'lat<'«l information. A lot of data has to be captured, stored and analyzed 
Ix'fon* ait<’mpling to perform any action on the system. Networks tend to grow very 
rapi<lly. If networks an* to work efficiently inspite of rapid growth it is necessary 
to <'Hpture a variety of data which will not only allow us to manage static networks 
hut a!s() j>lan ami manage the growth itself. As such, Network data capturing and 
inanageiuent soft wan* h<‘comes e.ssential for proper functioning of the network. 

('omnu'rcially available Network management software is quite good. But, in- 
house dev<'!opment of such software is desirable, since the functionality required 
at. a })articular site is very sensitive to the nature of the site and kinds of users it 
supports. For (example, in a networked University environment containing many 
.servers, workstations, PCs, and other special devices the proper distribution of user 
dirtH-t.ories on various file systems can be an important parameter. The program 
can be fine tuned to the local requirements. Also, commercial software is quite 
expensive, whertjas in-house development can be done without incurring much cost. 


1 



1 • 1 The Environment 


in 111 Kaiiptir lh<" ( (impuhT ( cnitrc is the main provider of computing resources. 
1 here is a eainpus wicie tilu'iaiet backbone connecting all the machines in the cam- 
pus. I !h* duininant operating system used is UNIX. TCP/IP is the protocol used 
ibr Hi'tworkim; purpusos. 

I lu' cumputor n’litrr has a host of UNIX machines, workstations, terminals, and 
X lornuiials. Sun NhSjSdK'^So] is used for providing distributed filesystem services 
to tlu' users, PC NKS is used to connect PC’s to the network. Internet connection 
is availahh' to all iht' users tlirough a gateway machine. Bridges, switches, routers 
and hubs eunnerl tlu* various t't.hernel segments. Plans are underway to upgrade 
tlu' tietwork. hy installng an ATM backbone and deploying 100 Mbps fast ethernet 
in plet< <' of lUMbps <“thernet. 


1.2 Motivation 

The ('t)inputer (’etjire personnel are res{)onsible for managing the network. The 
ludwtu'k is growing in size, and complexity. The staff is finding it difficult to cope 
with the cuinple.xity. .Network Management Software is very much needed in these 
circumstances. SNMP(Hiinpl<* Network Management Protocol) is a network man- 
agiuiu'ut protocol, but it is not installed on many of the components in the network. 
.\t) inv(*stm<uit.s ha\'e been made on Network management software initially, as the 
network was small. But, later on the network grew, and with it arose the need 
for inanag(‘mout software. In this thesis, an attempt has been made to develop a 
iK'twork monitoring tool, which will aid in network management. 


1.3 Network Monitoring 

Network monitoring tools monitor, analyze network traffic and suggest measures to 
b(* tak<iu up for improving the Network performance. Often, the capability to see 
what is moving on the cable is quite useful. A trace of the packets flowing on the 
network gives an indication of the usage pattern of the network. 
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iiy uUst'rving iho network traffic one can figure out facts like, which host is 
geiu'rat iiiu, luaxiinuin amount of traffic, which host is receiving maximum amount 
of packeMs, et<-. The dominant protocols in use can also be observed. In caae of NFS 
traiiic. on<> can determine the load on filesystems, find out the maximum NFS traffic 
generating clients, u.sers, etc. 

Ofltui tract's of tliis sort prove very helpful in making administrative decisions, 
like, moving lile systt'ins from one computer to another or moving files among filesys- 
It'ins. alkx at ing liome directories for new users, relocating existing user’s login areas 
etc. 

A network may further be divided into logical subnets, depending on the traffic 
patlt'rns obst'rved. For example, a set of hosts amongst whom the traffic is high, 
can be formed into a separate ethernet segment. 


1.4 Existing Software 

Lot of software already exists, to monitor network traffic and analyze it. 

tcptiumpjSMb], is a software to observe the network traffic. Packets, as they are 
iicjvvingt^n tin* in'twork, art* captured and displayed. The source machine, destination 
inachint*, protocol, timestamp and other information is displayed. Command line 
o|>tions for specifying protocols to monitor, source machine, destination machine, 
etc., art* availal)le. tepdurnp runs on almost all flavors of UNIX. 

rpc.tihtvd and traffic, both available on Sun machines, provide a graphical dis- 
play of the network traffic. 

On the NFS front, nfswatch[CM] is a very useful program. This program shows 
the; number of requests arriving onto filesystems, the number of requests emanating 
from client machines, users, and response time of the fileservers and other interesting 
details. Command line options for specifying source machine and/or destination 
machine, cycle time, total time of execution, etc., are available. 

nfstrace[Bla92] is another interesting tool. This software produces trace of the 
NFS activity as well as a plausible set of corresponding system calls in the client 

machine. 
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/•//?</ /(iSFa]. avaikhlo from Curtin University, is an Xll based tool which 
displays a r<‘pr<‘s<>ntation of real-time Ethernet communications, /nierman [SFb], 
also from C'tirtin I'nivor.sity, focuses on IP connectivity within a single segment. 

Lot of rt'lated software is available on the Internet, in all forms, source, binary, 
fiH'e and also for sale. 


1.5 Features of NETMON 

.XKTMOX is anotlu'r m^twork monitoring tool. It differs in one respect from the 
afor<‘said monitors. NKTMON stores the collected statistics for a user decided length 
of t inu'. say :i{) <lays. and can perform analysis on the stored data. Data is collected, 
suinmari/,<'ti and organized on a daily basis. This storage of statistics makes possible 
answt'riiig <jueries of t he type, ^ Which was the most accessed file system yesterday? , 
or. "Is tlu're any incrcase/decrease of network traffic a day after the network reor- 
ganization has Ix'en done?”, and similar ones. 

NE'l'MON has two component.s; Protocol Analyzer and NFS Analyzer. 

Protu<-ol AsiniyztT reeeive,s Network data promiscuously through a system ‘net- 
work tap’, and summarizes it into u.soful statistics, like Protocol wise breakup of the 
traiiic. application wise breakup of the traffic, etc. Traffic between various sets of 
hosts, subnets. s[)ecifi(‘d by the user, is also monitored. The collected statistics are 
stort'd for latcn- reference by the user. 

NFS Analyzer deals only with NFS traffic. NFS packets are captured, analyzed, 
and information like, total number of requests arriving on a filesystem, both reads 
and writc.s, numbtir of requests emanating from a client machine, number of requests 
issiK'd by a user, etc., are gathered. 

1.6 Organization of the Thesis 

(lhapt(T 2 discusses basic concepts about protocols, protocol headers and network 
monitoring mechanisms. Some packet capturing mechanisms are also pre- 
sented in this chapter. 
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('liaptcr .'5 discusses tlic design of NETMON. Some design issues pertaining to 
Nlc TMON arc liiscnsscd in this chapter. 

('hapt*'!' ! <liscusHcs the implementation details of NETMON. 

Chapter a di.scusses the experience with NETMON. Some observations of network 
usage ar<' presented. 

Chai)ter (> conchules the thesis and describes future work that can be done. 
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Chapter 2 
Background 


Not work Muiiitor.s capture packets on the network and extract useful information 
from them. To develop these monitors we need to know the structure of packets 
and protocols, hi very protocol has its own header format. Network monitors parse 
protect)! headers and generate statistics. Structure of ethernet packets and other 
prt)tt)col headers of interest to NETMON are discussed in this chapter. 


2.1 Packet Structure 

An t't heriu't packet si/.c can vary from a minimurh of 64 bytes to a maocimum of 1518 
bytt's. Every packet on the network contains the ethernet header. Ethernet header 
consist.s of 48 bit source ethernet address, 48 bit destination ethernet address, and 
a 16 bit protocol field. 

Next t.t) the ethernet header, we have the network layer protocol header. IP is 
tli<‘ network layer protocol in case of TCP/IP networks. Other protocol headers 
!ik(' Addrt'ss Re.solution Protocol (ARP) or Reverse Address Resolution Protocol 
(RARl^) may be present in place of the IP header. 

N('xt to th(‘ n<!twork layer protocol header, we have the transport layer protocol 
header. l’( IP and UDP are the transport layer protocols in case of TCP/IP networks. 
Internet (h)ntrol and Me.ssage Protocol (ICMP) header may also exist in place of 
TCP/UDI^ headers. 
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Next tu the transport layer protocol header, we have the application layer proto- 
col header. Some application level protocols run on UDP, while some run on TCP. 
For example ftp. telnet, http run on TCP, while RPC, TFTP run on UDP. 

h'ignre 1 j^ives the prottH'ol hit'rarchy. 



Figure 1: Protocol Hierarchy 
















2.1.1 IP header 


Tile IP lieailer contains a number of fields. Of interest to NETMON are 

• .souret' IP address 

• <lest illation IP address 

• k'n^tli of IP header 

• length of <Iata 

• proto<'oI 

Tlu' protocol field specifies protocol of the Transport layer, say TCP, UDP or ICMP. 

2.1.2 TCP header 

'I'he 'i'(iP iK'ader contains a number of fields. Of interest to NETMON are 

• .source port 

• d«'s1 illation port 

Souri'e port and (U'stination port contain TCP port numbers that identify appli- 
lation [iro^raius at the ends of the connection. A port is the abstraction that 
transport {protocols use to distinguish among multiple destinations (application pro- 
grams) within a given host computer. [Com95] 

2.1.3 UDP header 

I'lie UDP header contains various fields. Fields of interest to NETMON are 

• UDP source port 

• UDP destination port 

I'lie source port and destination port fields contain the 16 bit UDP protocol port 
numbers used to demultiplex datagrams among the processes waiting to receive 
them. I’he source port is optional. When used, it specifies the port to which replies 
should be sent; if not used, it should be zero. 



2.1.4 RPC header 


HP(’ St amis Cor Roinoto Procedure Call. RPC runs on top of UDP. There are two 
tyi)es of RP(’ packets. 

• KPCcall 

• 1^P(’ reply 

I RPC mil 

I'lvery RPC call pa<'kel contains a call header. There are a number of fields in the 
headi’r. Of t}K>.se only a few are of interest to NETMON. They are 

• program number. This field contains the RPC program number. 

• v{'rsion number. I'liis field contains the version number of the program. 

• pro<'('<lur<* number. 'I'lns field contains the remote procedure number, which is 
tt) b<’ e.xecuted. 

• m<‘ssag<‘ i<l. This field is used to match RPC replies with calls. 

I RPC reply 

Every RP(^ reply packet contains the reply header. The fields in the reply header 
of inten',st to NETMON are 

• nu^ssage id. This field is common to both call and reply headers. This field is 
us(;d to match responses with requests. 

RPC replies do not carry the RPC program number. Message id field has to be 
used to match replies with calls. 


Q 



2.1.5 Well known ports 

'i'lu' Op('rating System reserves some ports for standard services. Both TCP and 
I'DP ha\-(' defined a group of well-known ports. For example, every TCP/IP im- 
plenionfation that supports FTP, the File Transfer Protocol, assigns port 21 to 
it[Sle91]. Tl-l'P, IVivial File Transfer protocol, is assigned the UDP port of 69. 
Som<' ot.lu'r w<'ll known ports are 

• t('lnet - 23 

• smtp - 25 

• finger - 79 

• bootps - 67 


2.2 Network File System 

In this st'cf.ion a l)ricf description of the Network File System is given. The Sun 
Nh'twork Programming manuals [Sun88] provide more details. 

'I'ht' Sun N<M.work Filesystem (NFS) protocol provides transparent remote ac- 
cess to shared files across networks. The NFS protocol is designed to be portable 
across different machines, operating systems, network architectures, and transport 
protocols[Inc89]. 

An NFS network consists of servers and clients. A particular machine can be a 
client or a server or both. Server machines export filesystems for access by clients. 
Client machines mount remote filesystems in their local hierarchy for accessing them. 

llcmotc files and directories are referred to by a file handle. File handle formats 
vary from implementation to implementation. File handles are opaque to the client 
machine and are only understood by the server. 

The interface between client and server is defined in terms of 17 RPC operations. 
There are operations to read or write files(read, write), create or remove files (create, 
remove), create or remove directories (mkdir, rmdir), get file attributes (getattr), get 
filesystem attributes(statfs) and for other functions. 
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(’lit'iit niac'liiiit's cache the remote files for better performance. Cache coherence 
is maintained by the client machine by checking the last write time of the file at the 
s('r\-cr. hc'fore using the cached data. 

.NFS is built on lop of RPC. An RPC transaction consists of a call message from 
the client to the server and a reply message from the server to the client. RPC calls 
are t ran.sniitt(’d u.sing the UDP/IP protocols. The call message contains program 
munhtn", version number and procedure number. There is also a unique transaction 
idi'iitifier which is included in the reply message to enable the client to match the 
rt'ply with its call. 'I'hc data in these messages is encoded in an “external data 
^'presentation" (XDR), which provides a machine-independent standard for byte 
order, etc. 

NFS is a stateless protocol. No client site information is stored at the server. 
The absence of any client site information at the server makes crash recovery simple. 

2.3 Capturing Packets 

User pro<'('ss<'s can <'a.pturo packets on the network in a system dependent manner, 
h'or this, tlx' etiiernct interface has to be configured to operate in promiscuous mode. 
'I'liis s('tt,ing can only be done by the superuser. On some systems, ordinary users 
arc^ allowed to listen on ethernet interfaces, while on some other systems, only root 
can listen to the packets. For example, on DEC OSF/1, ordinary users can snoop 
on to the network, while on Sun machines, only the root is allowed to do so. 

In this section, we discuss ways to capture packets on DEC OSF/1 and Sun OS 
systems. Every system has its own way of providing data link level access to users. 

2.3.1 PacketFilter 

In DEC OSF/1 systems, packetfilter[MRA87] provides access to network packets. 
This section gives a brief introduction to packetfilter. Further details can be obtained 
from the manual. 

The packet filter pseudo device driver provides a raw interface to Ethernets and 
similar network data link layers [Dig94]. The packet filter driver is kernel-resident 
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codt’ provi{l('d by Di'X^ ()SI‘/1 operating system. The driver appears to applications 
as a sot oi oharaotor special files, one for each open packet filter application. 

I'or op<'iiing those special files, the Operating System provides the pfopen library 
routine'. Associated with each open instance of a packet filter special file is a user 
settable packet filter “program”, that is used to select which incoming packets are 
d('livere(l by that packet filter special file. 

Rc'ads from tliese files return the next packet from a queue of packets that have 
inatche<I flu* filter. Writes to those files, transmit packets on the network, with each 
writ(’ opi'ration generating exactly one packet. 

'I’lu' packt'f filters treat the entire packet, including headers, as uninterpreted 
data. 'I’lu' u.ser must supply the headers for transmitted packets (although the sys- 
tem makes sure that the source address is correct) and the headers of received pack- 
ets are delivered to the user. The packet filter mechanism does not know anything 
about the data portion of the packets it sends and receives. 

'fhe packet fiit.er supports a variety of different ethernet data-link levels say 
lOMhps ethernet, KDDI. 

2.3.2 Network Interface Tkp 

Sun’s Ni'twork Interface 'rap(NIT) is the facility provided by Sun machines to pro- 
vide link-level network access. This facility comprises of a set of modules which 
collectively provide facilities for constructing applications that require link-level net- 
work access. They are explained below : 

• nitjf is the component that provides access to the network interfaces. 

• niLpf is the packet filtering module which can be used to specify filters for 
accepting packets. 

• nitJuf is the module that buffers incoming messages, thereby, reducing the 
number of system calls and associated overhead required to read and process 
them individually. 

NIT clients mix and match these components, based on their particular re- 
quirements. Examples of applications, which use NIT include rarpd, which 
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is a user-level implementation of the Reverse ARP protocol, and etherfind 
which is a network monitoring and trouble-shooting program available on Sun 
machines. 



Chapter 3 


Design of NETMON 


NETMON has four components in it : the protocol analyzer processes packets 
and classifies them according to the protocol used, the nfs analyzer analyzes 
the NFS traffic, the storage unit stores the collected statistics and retrieves 
t.lu'in on demand, and the user interface interacts with the user. The overall 
design of NETMON and design of the individual components is described in 
this chapter. 


3.1 Architecture of NETMON 

The packet capture unit is the interface with the Operating System. This 
interface keeps supplying NETMON, the packets flowing on the network in 
real time. The protocol analyzer takes each packet, strips the protocol headers, 
classifies the packet according to the protocol used at various levels, say at 
network layer level, at transport layer level and at application layer level. The 
corresponding counters are updated on each occurrence of the packet. 

The nfs analyzer picks up NFS request packets only, i.e. requests going from 
client machine to the fileserver. As NFS is based on RPC/XDR, the packets 
have to be reconstructed. This is needed because data in XDR format has to 
be converted to local machine format. After reconstructing the packet, the 



server filesystem, client machine, and the user on whose behalf this request 
has been issued, are determined. The counters associated with the filesystem, 
client machine and user are then updated. 

The fitorage unit stores the statistics collected by the analyzer programs, the 
Ilfs analyzer and the protocol analyzer. These statistics are retrieved when the 
user ri'ciuests them. 

The UHcr interface is a character-based interface and is quite simple. Queries 
to obtain traffic details over a period of time are supported. Traffic details for 
a day, an hour or for a 5 minute interval can be obtained. Traffic summaries 
for the last n days, n hours, or n 5 minute intervals are also available. In case 
of protocol analyzer, additional operations, to add/ delete hosts and subnets to 
monitor, to generate a list of hosts, subnets being monitored and to perform 
other miscellaneous functions are provided. 

Figure 2 (k^picts the Architecture of NETMON. 
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Figure 2: Architecture of NETMON 












3.2 Protocol Analyzer 


'Fho protocol analyzer runs through the ethernet packets, stripping the pro- 
tocol headers and extracts the protocols and applications associated with the 
packet . 

An ethernet packet is taken and the network layer protocol is found out from 
tlu' 'protocol' held of the ethernet header. 

X('xt. t he ethernet header is stripped off. The packet might be an ARP, RARP, 
IP packet or others. For ARP and RARP, no further processing is done as 
t,hey do not contain any further encapsulation. 

After extracting an IP packet, we observe the ‘protocol’ field. This field may 
point to TCP, UDP or ICMP protocol. For ICMP packets, no further pro- 
c.essing is required. The iemp packet counter is incremented by one on every 
occurrence of an ICMP packet. 

After i'xtracting a 1’CP packet, the source port and destination port fields in 
t,h<‘ 'I'CP header are examined. Some standard applications have well-known 
ports associated with them. For example, FTP runs on 21, telnet on 23, and 
SM'rP(nuul) on 25. Depending upon the source port or the destination port, 
the application is found out. If the application cannot be determined in this 
way, the packet is treated as belonging to miscellaneous TCP applications. 
The application level protocols currently recognized by NETMON are ftp, 
telnet, X, http, smtp and nntp. 

For a UDP packet, the processing is similar. We again observe the source 
port and destination port and try to figure out the application. If we can’t, 
the packet is tested for a RPC packet. In case of a RPC call, the RPC 
program number is examined. NFS, YP, MOUNT, PCNFSD are some of the 
applications running on RPC which are recognized by NETMON. In case of 
a RPC reply, no further processing is required. All the packets are grouped 
into the rpc replies category. Remaining packets are treated as miscellaneous 

UDP applications. 



The protocol analyzer, analyzes the overall network traffic. Options are also 
available to monitor traffic between 

— a particular host and set of other hosts. 

— a particular host and a set of subnets. 

— a subnet and a set of other subnets. 


3.3 NFS Analyzer 

NFS analyzer, as the name suggests, analyzes the NFS traffic going onto 
all the exported filesystems and generates statistics on filesytem usage levels. 
NFS request packets on the network are captured. The packet is reconstructed, 
i.e. data in XDR format is converted to the local machine’s format. From the 
reconstructed packet, the server filesystem, the client machine and the user on 
whose behalf the request has been issued are found out. The corresponding 
counters are then updated. 

'['he NFS request packets arriving onto a filesystem are classified as NFSJIEAD 
or NFS.WRITE, depending on, whether the the execution of the NFS proce- 
dure contained in the packet, results in a read operation or write operation at 
the fileserver. 


3.4 Storage Unit 

This unit is responsible for storing the statistics collected by the protocol 
analyzer and the nfs analyzer. 

The statistics are collected by the analyzer programs continuously. After ev- 
ery five minute interval, the statistics collected in the interval are stored and 
counters reset. Again, after every one hour interval, the statistics collected in 
the preceding hour are summarized and stored. Similarly, after every twenty 



four hour interval (a day), the statistics generated during that day are sum- 
marized and stored. In this way, data collected is stored in units of day, hour 
and five minute intervals. 

Currently, statistics summaries for a maximum period of 30 days are stored 
by NETMON. 

3.5 User Interface 

The User Interface is quite simple. Only a character based interface is pro- 
vided. The analyzer program act as server, while the user interface program 
acts as the client. UDP is the protocol employed for the client-server interac- 
tion in case of protocol analyzer, while the nfs analyzer uses TCP for the same 
purpose. 

The client program accepts input from the user, and sends these requests to the 
a.nalyzer program for processing. The server processes the requests and sends 
responses to the client, i.e. the user interface program. The user interface 
program then displays the results obtained. 

The following queries are supported by both the programs, the nfs analyzer 
and the protocol anaJyzer. 

- Get statistics collected in the last 'n’th day interval. 

- Get statistics collected in the last 'n’th hour interval. 

- Get statistics collected in the last 'n’th five minute interval. 

Similarly, queries to observe summaries over the last ‘n’ days, ‘n’ hours and 
‘n’ five minute intervals are available. 

In case of protocol analyzer, commands, to add a host(or subnet) to monitor, 
to delete a host(or subnet) being monitored, are provided. A command to 
obtain the startup time of the analyzer is also provided. 



3.6 Design Decisions 


The protocol analyzer and the nfs analyzer have been allowed to exist as two 
separate programs. This is because, the nfs analyzer is specific to NFS, and 
is useful only when there is a lot of NFS traffic on the segment. The protocol 
analyzer is of a very generic nature and can be used on any ethernet segment. 

The Ihser Interface is quite simple. Only a character based interface is pro- 
vided. 'I'he functionality to be built into the system is given more importance 
than the user interface. 

Protocol analyzer monitors traffic between a particular host and a set of sub- 
nets, or between a subnet and a set of other subnets. By subnet, we mean a set 
of IP addresses, but not exactly the set of hosts in the domain. For example, 
all hosts with address prefix of 144.16.163 are treated to be part of the subnet 
144.16.163.*. This has been done to make implementation simpler. Domains 
and the hosts in them, have to be defined for exact working of these options. 

The minimum monitoring interval has been fixed at five minutes. This software 
is mainly used for performing retrospective analysis of traffic at macro intervals 
of time, say on a daily basis. As such, the minimum monitoring interval 
need not be at a micro level, say every second. Micro level interval updates 
are used by software like Etherman[SYa], which display real-time Ethernet 
communications instantaneously. 



Chapter 4 


Implementation Details 


The •protocol a'nalyzer and the •nfs analyzer exist as independent programs. 
The statistics storage part is again similar for both of them. Only what is 
stored differs, not how it is stored. The User Interface of both the programs is 
identical, except for the presence of a few additional options for the protocol 
analyzer. This chapter discusses the implementation details of NETMON. 


4.1 Protocol Analyzer 

The protocol analyzer is implemented as a separate module. Some major steps 
in the execution of the program are explained below. 

4.1.1 Initialization 

This is the first step performed in the program. Basic initialization chores are 
performed in this step. A socket is created and set up for asynchronous I/O. 
This is done for accepting user’s requests from time to time. UDP port number 
7419 is used by the protocol analyzer, while the nfs analyzer uses TCP port 
number 7219 for the same purpose. The ethernet interface is then properly 



configurocl to accept packets in promiscuous mode by a series of ioctl calls, 
kinally, various data structures are initialized or allocated memory as needed. 

4.1.2 Input Piles 

I'lic program has two configuration files, hosts.monitor and mapfile. The 
former is used to specify the list of hosts and subnets to monitor. The later 
is iu‘ed('(i by the nfs analyzer and is a feature originally present in nfswatch. 
'riu' two input files and their contents are discussed below. 


Monitor File 

NETMON monitors the overall network traffic in the ethernet segment. In 
addition, it also allows one to monitor the following types of traffic. 

— 'IVaffic ‘arriving to’, and ‘generated from’ a host. This type of monitor is 
redorred t.o as a ‘11’ monitor hereafter. 

~ 'Traffic flowing between a particular host and a set of other hosts. This 
type of monitor is referred to as a ‘HH’ monitor hereafter. 

— Traffic flowing between a particular host and a set of other subnets. This 
type of monitor is referred to as a ‘HN’ monitor hereafter. 

— Traffic flowing between a particular subnet and a set of other subnets. 
This type of monitor is referred to as a ‘NN’ monitor hereafter. 

These monitors are setup at startup time by specifying them in the hosts.monitor 
file. Entries in the file are explained below. 

A ‘H’ monitor is set up by specifying the hostname or IP address of the host, 
one per line. For example, 

yamuna 

monitors traffic ‘proceeding to’ or ‘arriving from’ yamuna. 
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A 'ini monitor is set up by specifying the hostname of interest, followed by 
number of secondary hosts, and then their names/IP addresses. Again one 
HH entry is specified on one line. For example, 

csexJ 2 csealphal csealpha2 

monitors traffic flowing between csexl and csealphal, csealpha2 combined. 
Number 2 indicates the two auxiliary hosts of interest to csexl. 

A 'I IN” monitor is set up by specifying the hostname of interest, followed by 
tlu' number of subnets, and then the subnet addresses. For example, 

cti (‘.spare 1 1 144.16.163.* 

monitors traffic flowing between csesparcl and hosts with a IP prefix of 144.16.163. 

A ‘NN’ monitor is set up by specifying the subnet of interest, followed by the 
number of secondary subnets, and then their subnet addresses. For example, 

144.16.162.* 1 144.16.163.* 

monitors traffic flowing between hosts with IP prefix of 144.16.162 and hosts 
with IP prefix of 144.16.163. 

A siunplo input file is given in the Appendix. 


Msipfile 

The map file is an accoutrement with the nf swatch program. As we have used 
nfswatch code in our program, our program too needs it. 

The mapfie contains a list of device names and file system names (one pair per 
line). The program reads pairs of the file system device specifications (the file 
server’s name/address, and major number, minor number of the device) and 
the proper names of the file systems from mapfile. Each line should contain a 
string representing what nfswatch would normally print, and then separated 
from that by whitespace, the name that is preferred. For example: 

csealphal (8,103 0) csealphal :/ 1 d2 
csesunl(7,6) csesunl:/var /spool/mail 
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1 lie pioit'iiod iiiuncs are printed while displaying filesystem names, rather 
than the less readable filesystem device specifications. 

4.1.3 Parsing Packets 

From the raw etliernet packet, the higher level protocols are found out by 
gradually siri[)ping the headers and noting protocol types. Protocols and 
tilt' id's eorrespontling to them can be found in the system include files. For 
example, I'C’P's number is 6, while UDP’s is 17. By observing the protocol 
id’s, the network level, and transport level protocols are found out. 

I’he application level protocols are found out in a slightly different way. The 
port numbers, obtained from TCP/UDP header are examined, and if they 
correspond to any of the well known ports, we get to know the application 
from the port number. Some applications using well known ports are, ftp - 21, 
t.elnet - 211, snitp - 25, tftp - 69. 

UDP [jackets may have to bo explored further, as they may be encapsulating 
liP(! packets. R.P(1 packets are of two types, call and reply. Every RPC 
call [jacket, contains the program number in it. Some common RPC programs 
are NFS, YP, MOUNT etc. RPC reply packets do not contain any program 
number, so they are all bundled into rpc replies category. 

The program maintains counters in long unsigned integers. Structures are 
used to define counters. 

The following structure is used to store the packet count of protocols at the 
network layer level. 

typedef struct ■( 

LN_COUNTER ip.cnt; /* IP packet counter */ 

LN_COUNTER arp.cnt ; /* ARP packet counter */ 

LK_COUNTER rarp_cnt; /* RARP packet counter */ 

L1I_C0UNTER nw.others; /* others counter */ 

} NW_LEVEL; 
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Tlu' followijig structure is used to store the packet count of protocols at the 
transport layer level. 

typedef struct { 

LN_COUIITER udp.cnt; /* UDP packet counter */ 

LN_COUNTER tcp_cnt; /* TCP packet counter */ 

LN.COUNTER icmp.cnt; /* ICMP packet counter */ 

LN .COUNTER tp.others; /* others */ 

} TP.LEVEL ; 

'File following structure is used to store the packet count of protocols at the 
application level. 

typedef struct i 

LN.COUNTER rpc.call; /* RPC calls */ 

LN.COUNTER rpc.cnt; /* RPC replies 
LN.COUNTER nfs.cnt; /* NFS calls */ 

LN.COUNTER telnet.cnt; /* TELNET packet counter */ 
LN.COUNTER ftp.cnt; /* FTP packet counter */ 

LN.COUNTER smtp.cnt; /♦ SMTP packet counter */ 

LN.COUNTER www.cnt; /* HTTP packet counter */ 

LN.COUNTER nntp.cnt; /* NNTP packet counter */ 

LN.COUNTER xserver.cnt; /* X traffic counter */ 

LN.COUNTER tftp.cnt; /* TFTP counter */ 

LN.COUNTER yp.cnt; /* Yellow pages traffic */ 

LN.COUNTER mount.cnt; /* NFS mount protocol count */ 
LN.COUNTER pcnfsd.cnt; /* PC-NFSD traffic count */ 
LN.COUNTER tcp.app.others ; /* other tcp apps */ 
LN.COUNTER udp. app. others ; /* other udp apps */ 

y APP.LEVEL ; 

The Protocol Analyzer uses the following basic cell for storing traffic details 
observed in a unit of time. This unit may be a day, or an hour, or 5 minutes. 
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struct < 

LN.COUNTER raw^cnt; /* raw ethernet pkt's cat */ 
LN.COUNTER bdcst.cnt; /* ethenet broadcasts */ 
NW.LEVEL nw.lvl; 

TP.LEVEL tp_lvl; 

APP.LEVEL app.lvl; 

int from.secs; /* start time of the monitoring ♦/ 
int to_secs; /♦ end time of the monitoring */ 

> CELL ; 

4.2 NFS Analyzer 

^'I'S AnalyziT is t he second module of NETMON. It monitors NFS traffic 
It is hfis('<l on nfswatch. nfswatch is freeware and is available from many 
sit«-.s on tlu' net. nfswatch code has been liberally used in this module. NFS 
Attiilyzer work.s as follow.s : 

blit iaiizat ion for nfs analyzer is identical to protocol analyzer, in the sense that 
the etherrn't interface is configured in promiscuous mode, socket is setup and 
data .structures initialized. 

NFS Analyzer processes only NFS requests, not responses. NFS packets are 
picked up for scrutiny, by observing the transport level protocol(which is UDP 
in ca.so of NFS), and the RPC program number. Most implementations use, 
port number 2049 as NFS port, but this is not a standard practice. 

'I’he NFS packet’s data will be in XDR format when it is captured from the 
network. This data is deserialized using XDR decode routines. These routines 
are provided by nfswatch and are directly used. 

Once deserialized, we extract the NFS procedure and classify it as a NFS-READ 
or NFS.WRITE operation. 

The following NFS procedures are classified as NFS-READ operations, as their 
execution at the file server results in read operations. 
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- gctattr( ) Returns file attributes. This is like a stat call. 

- lookup 0 Returns file handle and attributes for a file in a directory. 

- readlinkQ Returns the string associated with the symbolic link file. 

- readQ Returns data from a file. 

- readdirQ Returns directory entries. 

- statfsQ Returns filesystem information. 

The following NFS procedures are classified as NFS-WRITE operations as 
their execution at the file server results in write operations. 

- setattrQ Sets the attributes of a file. 

- writeQ Writes specified number of bytes in the file. 

- create 0 Creates a new file and returns the file handle and attributes. 

- rtmoveQ Removes a file from a directory. 

- renarneQ Renames a file. 

- linkQ Creates a link to a file. 

- symlink() Creates a symbolic link. 

- mkdirQ Creates a new directory 

- rmdirQ Removes an empty directory. 

Thus each NFS packet is classified as a read or write operation. The client ma- 
chine issuing the call, and the user on whose behalf the call has been issued are 
extracted from the packet. The server’s address is extracted and the filehandle 
is decoded. Decoding NFS filehandles is a tricky issue, as various implemen- 
tations use their own proprietary formats. Again, filehandle decoding part is 
directly taken from nfswatch. 

For maintaining the count of ‘NFS requests’ arriving onto a filesytem, the 
program has the following data structure. 
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typedef struct _fs_ { 

my.devt nc_dev; /* device numbers of file sys */ 
my.fsid nc.fsid; /* for "learning'' file systems */ 
ipaddrt nc_ipaddr; /* keep track of server address */ 
char *nc_name; /♦ name of file system */ 

Counter cnt_nfsread; /*count file system read ops. */ 
Counter cnt.nfswrite; /*count file system write ops. */ 
Counter nc_interval; /* total requests this interval */ 
Counter nc.procCMAXNFSPROC] ; /* nfs proc counters */ 
struct _fs_ *fs_next; /* link field */ 

}■ WFSCounter; 

The purpose of each field is specified in comments. 

For maintaining the count of NFS requests emanating from a client machine 
the. program has the following data structure. 

typedef struct _cl_ ■{ 


ipaddrt 

cl_ipaddr; 

/* client IP address 

*/ 

char 

*cl_name; 

/* name of client system 

*/ 

Counter 

cl_interval ; 

/* requests this interva 

*/ 

struct 

_cl_ *cl_next ; 

/* hash chain link 

*/ 


} ClientCounter; 

For maintaining the count of NFS requests generated by a user the program 
has the following data structure. . 

typedef struct _ac_ { 

long ac_uid; /* authorization type */ 

char *ac_name; /* name of user id */ 

Counter ac.interval; /* requests this interval */ 


27 



struct _ac_ *ac_uext; /* hash chain link */ 

} AuthCounter; 

1 he NFS Analyzer uses the following basic cell for storing traffic details ob- 
served in a unit of time. This unit may be a day, or an hour, or a 5 mt 
interval. 

typedef struct _cell_ { 

NFSCounter *ptr_fs_counters; /* file system counters */ 
ClientCounter *ptr_cl_counters ; /* client counters */ 
AuthCounter *ptr_auth_counters ; /* Authentication counters */ 
int cnt_f sentries; /* No. of file system counters in cell */ 

int cnt_clentries; /* No. of client counters in this cell */ 

int cnt_authentries; /* No. of auth counters in this cell */ 

int from_secs; /*start time of monitoring interval*/ 
int to_secs; /*End time of monitoring interval */ 

} NFS.CELL; 

The statistics storage is akin to the one employed by the protocol analyzer. 

4.3 Statistics Storage and User Interface 

Statistics Storage unit is identical to both the analyzers. Only, what is stored 
changes, not how it is stored. There are 3 kinds of lists, days list, hrs list and 
mts list. These lists store the basic cells. A cell is the basic data storage unit 
and is different for both the analyzers. The cells are given above. 

The data, as captured from the network is first collected into current counters. 

After every five minute interval, data in the current counters is added to the 
tail of the mts list and the current counters are reset. After every one hour 
interval, the statistics of the last, 12 five minute intervals are added up to 
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uhi.uu fhr hour < <‘11. This roll is then added at the tail of the hrs list. After 
<>v.>ry T1 h<nu- int.-rval. th,- statistics of the last 24 hours are added up to obtain 
I hr <l..y < <‘11. i his cell is then a<ided at the the tail of the days list. The lists 
art' iiui)lriiirntr<l as circular queues. 

In < asr t.f NFS Analyzer, daily traffic is stored on disk file, while everything is 
in int'inory for the [jiotocol analyzer. 


Vsi'V IntVvfiUT 


r.srr int<‘rl'act‘ is iinplt'UKnited using the client-server paradigm. The User 
Intt'rlacr program is the client while the analyzer program is the server. Client 
prttgram acrt*pt.s injmt from the user, and sends it to the server. The server 
processes the rerjuesl and sends back the response. The client programs display 
th<'s<‘ rc'sponses. A list of the commands is given in the Appendix. 


4.4 Implementation Issues 

HTTP tlaenuni usually runs on the well known port number 80. Due to some 
reasons t!u' http daemon is now running on some other port on the HTTP 
proxy. Tlun'tTon', t radic ‘arriving from’ or ‘proceeding to’ the proxy on the 
new hit pti port is treated as http traffic. 

Tlu‘ X server port is also not a well known port. We are assuming the port 
numb(T 6000 as the X port. This is a valid assumption as most implementa- 
tions use the same port for the X Server. 

Only the number of packets is counted, not the number of bytes in the packet, 
lioth counts are desirable. Packet counts give the physical number of packets 
on th(^ wire, while byte count gives the bandwidth utilization levels. 
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Chapter 5 


Observations 


'{'!io Protocol Analyzer and the NFS Analyzer have ben tested thoroughly. 
Long traces of file system traffic and protocol summaries have been obtained. 
In thi.s chapter we discuss the observations that can be made after examining 
the colk'cted statistics. 


5.1 Experience with nfsanalyzer 

'Pile nfs analyzer has been run, both on the CSE segment and the CC seg- 
ment. 'I’he nfs traffic on both these segments is observed. In this section, the 
program’s output is analyzed. 

5.1.1 PileSystem load levels 

The nfs analyzer gives the traffic arriving on each exported filesystem in the 
segment. Sample output follows ; 

Start time = Sat Jan 4 16:07:01 1997 
End time = Sat Jan 11 16:07:01 1997 
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No. of active file systems in this interval = 45 


LIST OF FILE SYSTEMS 


SER:FS csesparcl : /dos 
SER:FS csealphal:/ld2 
SER:FS csealphal:/usr 
SER:FS godavari : Unknown 
SER:FS arjun (7, 2127360) 


read = 

2572045 

write = 

554609 total = 

3126654 

read = 

484416 

write = 

242600 total = 

727016 

read = 

155409 

write = 

0 total = 

155409 

read = 

67402 

write = 

42626 total = 

110028 

read = 

21788 

write = 

2126 total = 

23914 


The duration interval is 7 days. The start time gives the time when the 
monitoring interval started, and end time gives the time it ended. The next 
line gives the total number of filesystems onto which NFS requests have come. 
Next, we have a list of filesystems, and no. of read requests, write requests 
and total requests arriving onto them. The output is sorted so that busy 
filesystems come at the top of the list. 

The numbers are of little importance when taken in an absolute sense. Only a 
relative comparison would be meaningful. The /dos filesystem on csesparcl is 
the busiest filesystem. This filesystem contains DOS files, which are mounted 
on the PC’s through nfs. It also has system areas for some diskless workstations 
in the lab. 

/Id2 filesystem on csealphal is the next busy filesystem. This filesystem 
contains home directories of most of the users. 

/usr on csealphal contains read only binaries. Therefore, no writes are per- 
formed on this filesystem. 

godavari is a Linux PC, and it’s filehandle format is not recognized by the 
program. For recognizing new filehandle formats, new code has to be added. 
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(irjxin(T, 2127360) is the filesystem on arjun, which is being accessed from ma- 
c'hines in the CSE segment. The numbers in braces indicate the major and 
minor numbers of the filesystem. The major and minor numbers are printed, 
when no corresponding filesystem name is specified in the mapfile. 


5.1.2 Client machines list 

The nfs analyzer produces the list of client machines generating NFS requests. 
A sample client’s list looks as follows ; 

No. of active client machines in the interval = 71 

LIST OF CLIENT MACHINES 


Client csealphaS 
Client csealpha2 
Client rpt 
Client pc35 
Client 144.16.163.171 


requests = 2025728 
requests = 1937223 
requests = 1552453 
requests = 1030454 
requests = 145516 


There are 71 client machines which have issued NFS calls in the timeperiod 
of interest. The machine name, and the number of calls it has generated are 
given one per line. The output is sorted, so that most active client machine 
stands at the top of the list. 

5.1.3 Users list 

The nfs analyzer also generates the list of users, on whose behalf the NFS calls 
have been issued. A sample output looks as follows : 
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No. of active users in the interval = 240 


LIST OF USERS 
USER root 
USER rpt 
USER nobody 
USER naidu 
USER #9138 


requests = 2065999 
requests = 1559981 
requests = 924740 
requests = 718124 
requests = 44075 


There are 240 users issuing NFS calls in the monitored interval. The login- 
id of the user and number of requests made axe given, one per line. Again, 
the output is sorted, so that most active users top the list, root is the id 
used by all the system processes, nobody is a login id associated with PCNFS 
implementation. The uid is given if the login-id can’t be obtained from the 
local passwd server. 

Observing the NFS traffic for a long amount of time, say a month, helps us to 
find out any surges, or drops in traffic after a reorganization of the filesystems, 
home directories, etc. The effect of a reorganization exercise can thus be 
observed with the nfs analyzer. 

5.2 Experience with Protocol Analyzer 

The protocol analyzer has also been run on both CSE and CC segments. 
Observations made after examining the traffic are presented in this section. 
Overall network traffic in a sample five-minute interval is as follows : 
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GENERIC N/W TRAFFIC ANALYSIS 


Start time = Tue Feb 

4 17 

:56:09 

1997 

End time = Tue Feb 

4 18: 

01:09 1997 

Monitoring Duration 

O 

o 

m 

05:00 

raw cnt 

=: 

71224 

( 

100.00 ) 

bdcst cnt 

= 

66 

( 

0.09 ) 

ip cnt 

= 

70988 

( 

99.67 ) 

arp cnt 

= 

143 

( 

0.20 ) 

rarp cut 


0 

( 

0.00 ) 

nw others cnt 

= 

16 

( 

0.02 ) 

udp cnt 

ss 

39813 

( 

55.90 ) 

tcp cnt 

= 

31147 

( 

43.73 ) 

icmp cnt 

= 

28 

( 

0.04 ) 

tpothers cnt 


0 

( 

0.00 ) 

telnet cnt 


7007 

( 

9.84 ) 

ftp cnt 


143 

C 

0.20 ) 

smtp cnt 


49 

( 

0.07 ) 

WWW cnt 

= 

127 

( 

0.18 ) 

X server cnt 

= 

23225 

( 

32.61 ) 

nntp cnt 

= 

0 

( 

0.00 ). 

tcp other app 


596 

( 

0.84 ) 

rpc_call cnt 

= 

2137 

( 

3.00 ) 

rpc_reply cnt 

= 

17178 

( 

24.12 ) 

nfs calls 


16542 

( 

23.23 ) 

yp calls 

= 

523 

( 

0.73 ) 

tftp cnt 


1 

( 

0.00 ) 
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mount calls 
pcnfsd calls 
udp other app 


18 ( 0.03 ) 

0 ( 0.00 ) 

3414 ( 4.79 ) 

dropped = 5886 

oveflows(oumul) = 0 

'Die figures displayed are the absolute number of packets on the network in 
the given interval. The numbers in braces indicate the percentage of that 
component in the total traffic. The difference between the raw cat and sum 
of ip cat, bdcst cat, arp cnt^ rarp cat and nw others cat, gives a count of 
fragmented packets. In the above case, we have 11 such packets. 

From the output, it is evident that, UDP is the dominant protocol(56%), 
closely followed by TCP(44%). Of the UDP traffic, NFS is again the dominant 
protocol. We can see that nfs calls account for 23%, and rpc replies account 
to 24%. It should be noted that nfs replies count is bundled up with other rpc 
replies. Little amount of YP (yellow pages) traffic is also observed. 

In case of TCP traffic, X traffic is the most dominant one, followed by telnet, 
irrTP and others. 

dropped gives a count of packets dropped since the start of monitoring. 

Similarly, composition of traffic, ‘incoming’ and ‘outgoing’ for a host, flowing 
between a host and subnet(s), flowing between a subnet and other subnet(s) 
can be obtained. 
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Chapter 6 


Conclusions and Further Work 


Primarily our attempt in this thesis has been to develop a tool for network 
monitoring. The data collected by the monitor is to be used by the system 
administrators. A protocol analyzer for analyzing the overall network traffic 
is built. This tool gives protocol wise breakup of network traffic. It recognizes 
most of the commonly used protocols and applications, such as ftp, telnet, X, 
http, etc. 

An NFS Analyzer for analyzing the NFS traffic is also developed. It is modeled 
after nfsxuatch, except for the way it stores statistics. This tool generates the 
list of filesystems being accessed, list of client machines issuing NFS calls, and 
users responsible for these calls, and their load levels. These statistics are 
expected to be used by the system administrators in allocating filesystems to 
machines, users home directories to filesystems, and for other administrative 
decisions. 

Both the tools have been developed on DEC OSF/1, using the packetfilter 
mechanism for packet capture. The software can be made to run on other 
systems as well, by suitably changing the packet capture unit. libpcap[SMa], 
a system independent API, for user level packet capture can be used for this 
purpose. 
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Further Work 


'Phis project is the first step towards building a network management software 
for the IITK Computer Centre. As such, there is a lot of scope for further 
work. 

Currently, NETMON only collects statistics. The interpretation and analysis 
of the data generated, has to be done by the user. It would be very useful, 
if the analysis part is also done by the software. The ideal situation, wherein 
the software collects statistics, and analyzes them thoroughly, and suggests 
corrective actions for performance improvement, is desirable. Lot of work 
need to be done in this direction. 

The protocol analyzer is far from complete. RPC traific, especially RPC 
replies, need to be further classified. Right now, all RPC replies axe bun- 
dled into one category. Newer protocols, like IPV6 are to be recognized. Also, 
a capability, wherein the program can detect new protocols automatically and 
store information about them is desirable. 

On the NFS front, more work can be done. The procedure wise breakup of the 
NFS traffic is to be generated. Next, there is no way to correlate among the 
observed three entities, namely filesystems, client machines and users. This 
feature enhancement would do a lot of good to the program. Also, design and 
implementation for constructing user profiles, i.e., about their usage patterns 
of files, filesystems, and resources has to be done. 

Both the above tools have to be upgraded to work on 100 Mbps network as 
well, since the Computer Centre is planning to 'install these networks soon. 

Lastly, the User Interface needs a big face lift. Providing a graphical interface, 
and displaying the collected statistics graphically, by means of charts, graphs 
would make the program easy to use. 
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Appendix A 


User Manual 


NETMON can be used by system administrators interested in observing net- 
work traffic. Programmers also can use this tool for developing applications 
which need network traffic. 

NETMON consists of two components, the protocol analyzer and the nfs an- 
alyzer. The protocol analyzer captures all the ethernet traffic and produces 
protocol wise breakup of the network traffic. The nfs analyzer captures only 
Nb'S traffic and generates statistics on filesystem usage levels, etc. 

Installation The distribution comes in the form of a tar file, netmon.tar. 
Extract the files from the archive to see two directories created, PROTJPROG 
and NFS_PROG. The PROT_PROG directory contains the protocol analyzer 
program, while NFSJPROG contains the nfs analyzer program. Create the 
executables by typing ‘make’ in both the directories. The executables, nfsspy 
and nfsreport should be created in the NFSJPROG directory and protspy and 
protreport created in the PROT_PROG directory. 

Running 

nfsspy puts the ethernet interface in promiscuous mode and captures NFS 
request packets only. The statistics collected are stored by the program, nf- 
sreport accepts inputs from the user and obtains the traffic summaries from 
nfsspy. Both communicate through a TCP connection. 
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protspy is similar to nfsspy, except that it captures all the network traffic and 
si OH'S summaries of the observed traffic, protreport should be used to fetch 
t he data collected by protspy. 

Pldit the configuration files mapfile and hosts. monitor, to suit your environ- 
ment. The former is used by the nfs analyzer and the latter by the protocol 
analyzer. Run the two programs, protspy and nfsspy in the background. These 
programs keep collecting statistics till they are terminated. You can view the 
collected statistics through the user interface programs, nfsreport or protre- 
port. 

User Interface 

The Interface is as follows ; 

First, one has to enter a single character command. The program then prompts 
for arguments. The arguments are then to be entered in the appropriate 
format. The results are then printed on the screen or to a file. The commands 
and the arguments they take are listed below. 

Statistics Retrieval Commands 

- m Display statistics collected in the last nth five minute interval. 

Arg : n. A number between 1 to 60, specifying the interval of interest. 

- h Display statistics collected in the last nth hour interval. 

Arg : n. The hour number of interest, ranging between 1 and 24. 

- d Display statistics collected in the last nth day interval. 

Arg ; n. The day number of interest, ranging between 1 and 30. 

- M Display summary statistics over the last n five minute intervals. 

Arg : n. The duration of interest, ranging from 1 to 60. 

- H Display summary statistics over the last n hours of interest. 

Arg : n. Number of hours over which the statistic summaries are to be 
generated. Any number ranging from 1 to 24. 
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- D Display summary statistics collected over the last n days. 

Arg : n. llie number of days over which the statistic summaries are to 
generated. Any number ranging between 1 and 30. 

t 

Miscellaneous Commands 

- c Executes miscellaneous functions. 

Arguments : 

* uptime. Shows the time the daemon has started and, the time elapsed 
since its start. 

* print. Prints the results of the commands to a file res. out., rather 
than on to the screen. 

* unprint. Clears the ‘print to file’ setting. 

— ? Help command. Displays help information about the program. 

- X Leads to termination of the daemon program. 

— q Quits the Interface program. 

Protocol Analyzer Specific Commands The Protocol Analyzer has some 
culditiorial commands. They are 

— a Add a Host or subnet for monitoring. 

Arguments : 

* Enter hostname/IP address of the machine for host monitoring. 

* Enter hostname/IP address, number of auxiliary hosts and the name/address 
of auxiliary hosts for host to host monitoring. 

* Enter hostname/IP address, number of auxiliary subnets of interest, 
and the subnet addresses, for host to subnet monitoring. 

+ Enter subnet address, number of auxiliary subnets of interest, and 
the subnet addresses, for subnet to subnet monitoring. 

The format of the lines entered here should be identical to the one spec- 
ified in the hosts.monitor file. Please refer Appendix B for sample file. 
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n List s all the hosts, subnets being monitored currently, and lets the user 
select an entity for viewing statistics. 

.\rg : code. A number given as ‘code’ for one of the entities in the 
generated list. 

z Deletes an entity being monitored. Displays a list of hosts, subnets 
being monitored currently, and lets the user delete an entity. 

Arg : code. A number given as ‘code’ for one of the entities in the 
generated list. 
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Appendix B 


An Example Monitors File 


# File Name : hosts .monitor 

# Contains list of nodes to be monitored 

# Date : 2/10/96. 

csl 

yamuna 

pc35 

pc20 

cspl 

# Now some host to host monitoring, 
csexl 3 cdl pell csesparc2 
csealphal 1 csealpha2 

#Now for some host to net monitoring, 
cspl 1 144.16.163.* 
csp2 1 144.16.163.* 

#Now for some net to net monitoring. 
144.16.162.* 1 144.16.163.* 

144.16.161.* 1 144.16.162.* 
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Appendix C 


An Example FileSystem 
Specification file 


csealph.al(8,6) csealphal;/usr 
csealph.al(8,7) csealphal : /Idl 
csealphal(8, 1030) csealphal :/ld2 
csealphal(8, 1031) csealphal :/ld3 
csealpha2(8,7) csealpha2:/2dl 
csealpha2(8,2054) csealpha2:/2d2 
csealpha2(8,2055) csealpha2:/2d3 
csealpha3(8,2048) csealpha3:/3d3 
csesunl (7,6) csesunl : /var/spool/ mail 
csesunl (7 , 3) csesunl : / export/root 
csesunl (7, 14) csesunl :/usr 
csesparcl(7,15) csesparcl;/4ul 
csesparcl(7 ,14) csesparcl;/4u2 
csesparcl(7,16) csesparcl : /dos 
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